Carlo PescioPublications
A Few Words with Niklaus Wirth
Published in Software Development, Vol. 5 No. 6, June 1997.

Niklaus Wirth is one of the most influential thinkers in the software world. A professor at ETH Institute in Zurich, Wirth designed Pascal, Modula 2 and Oberon. In the early 1970s, he was one of the people who proposed program development by stepwise refinment. He's the author of many important books, including "Algorithms + Data Structures = Programs" (Prentice Hall, 1975) and "Systematic Programming" (Prentice Hall, 1973)He was awarded the Turing Prize in 1984, and has also received five honorary doctorates and several other awards.
It was a pleasure to ask him a few questions regarding today's state of software development, as well as that of the future. As you'll see, Wirth has very strong opinions on the subject, and he states them with absolute precision.

CP:
You are one of the most influential academics. Your work had a great impact on both the study and the practice of software development. However, in many cases, the university environment and the "real world" are, indeed, very different. When I talk with a professor and then with a programmer, I often notice that they think about software in very different ways. A recent IEEE survey of what lie ahead in software revealed that there is basically no intersection between the opinions of academics and practitioners. As one of the few whose work has been influential in both fields, what's your opinion (or perhaps your secret)?
NW:
If there is a secret at all, then it is that of being both a programmer and a professor. The division is rather unfortunate and the source of many problems. Professors typically spend their time in meetings about planning, policy, proposals, fund raising, consulting, interviewing, travelling, and so forth, but spend relatively little time at their drawing boards. As a result, they lose touch with the substance of their rapidly developing subject. They lose the ability to design; they lose sight of what is essential; and resign to teach academically challenging puzzles. I have never designed a language for its own sake. Instead, I've always designed a language because I had a practical need that was not satisfied by languages that where already available. For example, Modula and Oberon were by-products of the designs of the workstations Lilith (1979) and Ceres (1986). My being a teacher had a decisive influence on making language and systems as simple as possible so that in my teaching, I could concentrate on the essential issues of programming rather than on details of language and notation.Yes, the drifting apart of practice and academia is unfortunate.

CP:
You probably know about the "good enough software" concept popularized by Yourdon. In many senses, it's just a rationalization of what's happening in the software world: the first company hitting the market with a feature-rich product is more likely to win the battle than the careful, quality-seeking company. Do you think there is anything developers and software organizations can do about that? I guess many developers would be happy to be given more time to develop better software, but at the same time they are rushed in the name of corporate survival. "Educating the users" seems more a wild dream than a possibility.
NW:
"Good enough software" is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual's pride in his/her work has become rare. The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed. Nothing but economic success and monetary reward is acceptable. Hence our occupations have become mere jobs. But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensible luxury, but a simple necessity.

CP:
As you know, there is a large debate about software engineering as a profession. In fact, many software developers never had a strong education, or any significant experience. Do you think software engineers should be licensed, as other engineers? Should something be changed in the curricula of software engineers/computer scientist to make them more effective? What, in your opinion, is the ideal education a software engineer should have?
NW:
Recently I read a final report of a research project funded by the Swiss National Science Foundation. The project's naive goals were identified as follows: First, how can easy programming be achieved (in particular, for non-experts)? Second, how can a mechanism be realized that allows hiding the difficult parts of parallel programming?After more than 30 years of programming we ought to know that the design of complex software is inherently difficult. This despite of the fact that, for decades, the industry has been advertising programmers' positions by claiming that programming is easy. Later on, when doubts arose even to the advertisers, they switched to promising a wide variety of tools to facilitate the arduous tasks. Tools became the slogan; the right tools, paired with clever tricks and serious managenment methods, would work wonders. Then Edsger Dijkstra called Software Engineering "Programming in spite of the fact that you can't".
Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience, on precise, logic thinking; and on pedantic exactness. No magic will do. In the light of all this it is particularly sad that in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic. As a result, software engineering has become the El Dorado for hackers. The more chaotic a program looks, the smaller the danger that someone will take the trouble of inspecting and debunking it.

CP:
Speaking of education, many peoples think that it's easier to learn the object oriented paradigm if you don't have previous experience with another paradigm. This seems like a big mistake to me, because I feel that an experienced developer should have a knowledge of many paradigms. In my opinion, early software engineering works (like Parnas' papers) and programming classics like Systematic Programming are as useful today as they were years ago. What's your opinion?
NW:
Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that was done with procedural programming. The fist such concept is that of the procedure bound to a composite variable called object. (The binding of the procedure is the justification for it being called a method). The means for this binding is the procedure variable (or record field), available in languages since the mid 1970s. The second concept is that of constructing a new data type (called subclass) by extending a given type (the superclass).
It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass. An interesting phenomenon is that many people learned for the first time about the important notions of data type, of encapsulation, and (perhaps) of information hiding when introduced to OOP. This alone would have made the introduction to OOP worthwhile, even if one didn't actually make use of its essence later on.
Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming. Static modularization is the first step towards OOP. It is much easier to understand and master than full OOP, it's sufficient in most cases for writing good software, and is sadly neglected in most common languages (with the exception of Ada).
In a way, OOP falls short of its promises. Our ultimate goal is extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system. EP implies that the addition of a module is possible without any change in the existing modules. They need not even be recompiled. New modules not only add new procedures, but - more importantly - also new (extended) data types. We have demonstrated the practicality and economy of this approach with the design of the Oberon System.

CP:
Recently I come across an advertisement for Borland Delphi (which as you know is a sort of O.O. Pascal with extensions for event handling) that said "Delphi 2.0 gives developers a language almost as readable as BASIC...". Apparently it was a quote from a review of the product. But it sounded so terribly wrong to me. "Almost as readable" as a language without a sound notion of data type? On the other hand, we cannot hide the fact that to a large extent, basic (Visual Basic) has won on the market, and is probably the first example of a commercial language with a huge market of components. As the father of Pascal, what is your opinion? Did basic really win? If so, why?
NW:
We must be careful with words like "readable", "user friendly", etc. They are vague at best, and often refer to taste and established habits. But what is conventional need not necessarily also be convenient. In the context of programming langauges, perhaps "readable" should be replaced by "amenable to formal reasoning". For example, mathematical formulas are hardly what we might praise as easily readable, but they allow the formal derivation of properties that could not be obtained from a vague, fuzzy, informal, user friendly circumscription. The construct WHILE B DO S END has the remarkable property that you may rely on B being false after the statement's execution, independent of S. And if you find a property P that is left invariant by S, you may assume that also P holds upon termination. It is this kind of reasoning that helps in the reliable derivation of programs, and that dramatically reduces the time wasted on testing and debugging. Good languages not only rest on mathematical concepts which make logical reasoning about programs possible, but also on a small number of concepts and rules that can freely be combined. If the definition of a language requires fat manuals of hundred pages and more, and if the definition refers to a mechanical model of execution (i.e. to a computer), this must be taken as a sure symptom of inadequacy. But alas, in this respect, 1960'Algol was far ahead of most of its successors, in particular of all those that are so popular today.

CP:
Another very popular language is C++. I know you are not particularly fond of it, and that in many cases, a safer language could be better. However, sometimes I wonder if it wouldn't be wiser to help programmers instead of battling them. For instance, in many cases C++ programmers would be happy to use a safer version of the language: not all of them are so concerned with 100% compatibility with C. A version of C++ were pointers and arrays are clearly separated, and were you get a warning when (e.g.) you assign a float to a long, and so on, would help them to write better programs and still not require to learn a completely new language. I understand that it is more pleasing to design a pure language than trying to make a fragile one safer, but then, if just a handful of peoples use this pure language, are we really advancing the state of the software development?
NW:
My duty as a teacher is to train, educate future programmers. In trying to do this as well as possible, I present fundamental notions as clearly and succinctly as possible. I certainly do not let an inadequate notation hinder me in this task. If students have grasped the important ideas and have gained a certain versatility and familiarity with the subject, they find no difficulty in adapting to other languages if required (although they typically complain about the new inconveniences). I do not see why anyone would call this "battling programmers". One may indeed wonder why nobody in the vast software industry has undertaken the task proposed by you: Defining a safe subset of C++. I can figure out two reasons: (1) The software world is eager for "more powerful" languages, but not for restrictive subsets. And (2), such attempts are doomed to fail just like attempts to strengthen the structure of a house built on sand. There are things that you simply cannot add as an afterthought.

CP:
Isn't the software development community focusing too much on technical issues, forgetting that software development is mostly a human activity? For instance, I think that one of the reasons for the popularity of BASIC and C is that their relative lack of constraints allows for some "local solutions" (euphemism for patch :-) to be introduced late in the development cycle. We all know that we should carefully design software before going to code. But we also know very well that, in most cases, management does not want to pay now for long term benefits. This is one of the reasons some peoples are not so happy with OOP. Hence, software is routinely patched when it's already in an advanced state of development. A language that lets that happen without too much concern will be more widely used than one which requires a large investment in up-front design. But then we continue to bash programmers for being "dirty" when in fact they are just playing in the real world, not in an ideal world. Wouldn't be better to think about programming languages with more consideration for human issues?
NW:
Software development is technical activity conducted by human beings. It is no secret that human beings suffer from imperfection, limited reliability, and impatience - among other things. Add to it that they have become demanding, which leads to the request for rapid, high performance in return for the requested high salaries. Work under constant time pressure, however, results in unsatisfactory, faulty products. Generally, the hope is that corrections will not only be easy, because software is immaterial, but that the custormers will be willing to share the cost. We know of much better ways to design software than is common practice, but they are rarely followed. I know of a particular, very large software producer that explicitly assumes that design takes 20% of developers' time, and debugging takes 80% . Although internal advoctates of an 80% design time vs. 20% debugging time have not only proven that their ratio is realistic, but also that it would improve the company's tarnished image. Why, then, is the 20% design time approach preferred? Because with 20% design time your product is on the market earlier than that of a competitor consuming 80% design time. And surveys show that the customer at large considers a shaky but early product as more attractive than a later product, even if it is stable and mature. Who is to blame for this state of affairs? The programmer turned hacker; the manager under time pressure; the business man compelled to extol profit wherever possible; or the customer believing in promised miracles?

CP:
It seems to me that most modern programming languages are feature-loaded to the point that many programs require 20% of the language (or less). But most of these features are about increased flexibility, not about increased safety. For instance, the old rule "declare before use" was a recognition that programmers make errors, and enforcing that rule allowed the compilers to detect some errors. Likewise, the "obsolete" clause in Eiffel is a recognition that some portions of the code become obsolete, but without a compile-time warning most programmers will continue to rely on them. Who has the time to read comments and documentation when the product must ship immediately? However, while I've seen red-hot debates about the usefulness of a "finally" clause in C++, I've seen a relatively small interest in how to protect the programmers (as humans) from themselves. What's your opinion?
NW:
The wealth of features of many languages is indeed a problem rather than a solution. A multitude of features is another consequence of the programmers' belief that the value of a language is proportional to the quantity of its features and facilities, bells and whistles. However, we know that it is better if each basic concept is represented by a single, designated language construct. Not only does this reduce the effort of learning, but it reduces the volume of the language's description and thereby the possibilities of inconsistency and of misunderstanding. Keeping a language as simple and as regular as possible has always been a guideline in my work; the description of Pascal took some 50 pages, that of Modula 40, and Oberon's a mere 16 pages. This I still consider to have been genuine progress. The relevant value of high-level programming languages depends on the quality and suitability of the abstractions they offer. An example is the abstraction called number, or that of a logical (truth) value, replacing concrete bit strings. The value of such an abstraction rests on its integrity. In the case of numbers, only arithmetic operations must be applicable, independent of the fact that also logical operations could be applied to the bitstrings representing the numbers.
Another case is the notion of the array with a given number of elements identified by ordinal numbers (indices). It must be guaranteed that no element can be accessed with an invalid index, despite the fact that the resulting address computation would point to some existing storage cell - probably holding another variable. The abstraction we're talking about here is the important concept of data type, and we point out that its value rests on the fact that a compiler will verify that the rules governing the types are obeyed, that the compiler will guarantee the abstraction's integrity. If a system fails to do this, if it allows a logical operation to be performed on numbers, or if it fails to indicate array access with invalid index - just to name two examples - it is hardly worth being called a high-level language system. However, most widely used systems are exactly of this nature, and the offered abstraction can be violated freely with the added "benefit" of innumerable software tools that help inspect how the abstraction is in fact represented internally in order to find out what went wrong.
It is particularly ironical that languages with fixed structural patterns for statements and data types, and with constructs for modularization and information hiding, are widely regarded as restrictive, cumbersome, and creativity-hindering. Indeed, programming with a structured, strongly typed language usually requires a greater amount of careful deliberation, and this is considered as detrimental (remember that programming is advertised as being easy). The irony of the matter is that the time gained by not having been required to comply with structural rules, is lost many times over by finding errors later on - in the field, perhaps by the dissatisfied customer. The weather forecast promises not much change. The concepts and the languages enabling a beneficial development of programming into a serious engineering profession have been with us for many years, but they remained largely unused, and the trend rather leads further away from them instead. It looks like software will remain a hackers' El Dorado for some time to come. Certainly, computers will not complain. I remember a long discussion in an academic seminar in the mid 1970s, when the word "software crisis" was in full swing and the notion of correctness proofs of programs was put forward as a possible remedy.
Professor C.A.R. [Tony] Hoare, the speaker at the seminar, had eloquently presented the principles and the advantages of correctness proofs replacing testing. After a long discussion about the pros and cons Jim Morris [department head at Carnegie Mellon University and developer of principles like inter-module protection and lazy evaluation] got up and disarmingly asked: "But Tony, what is your answer if we frankly confess that we dearly love debugging? You want us to abandon our most cherished enjoyment?"
Yet, I am convinced that there is a need for high quality software, and the time will come when it will be recognized that it is worth investing effort in its development and in using a careful, structured approach based on safe, structured languages. For the time being, however, this is practicable only for some "niche products". The niche will expand when a growing number of people will voice their dissatisfaction with poor software.